Today's mobile network architecture, a so called Evolved Packet Core (EPC) architecture, is described in Third Generation Partnership Project (3GPP) Technical Specification (TS) 23.401 and 3GPP TS 23.402. An overview of the EPC architecture 100 is illustrated in FIG. 1. An user equipment (UE) 101 (or mobile device) attaches to a network, e.g. via a radio access network such as evolved-UMTS Terrestrial Radio Access Network (UTRAN) 102, where UMTS stands for Universal Mobile Telecommunications System, and receives an Internet Protocol (IP) address. The UE uses that IP address to communicate with peers on a Packet Data Network (PDN) 103. Such PDN is in most cases the Internet, but could also be an operator's IP service like IP Multimedia Subsystem (IMS), Public-switched telephone network Simulation Subsystem (PSS) or the like. The PGW (PDN Gateway) 104 provides access towards one or more PDNs 103. There is a logical IP tunnel, called PDN connection, between UE and PGW.
All traffic of a PDN connection is routed through one and the same PGW 104. The IP address of that PDN connection, i.e. the UE's IP address, topologically belongs to the PGW 104. The PGW 104 thus acts as an anchor point for that IP address. Wherever the UE 101 moves, the anchor point remains the same. This way the peer on Internet, such as the PDN 103, does not notice the movement of the UE 101.
A PDN connection consists of three segments: the segment between UE and Base Station (BS), in FIG. 1 denoted as E-UTRAN 102, the segment between the BS 102 and SGW (Serving Gateway) 105, and the segment between the SGW 105 and the PGW 104. The latter two are implemented by General Packet Radio Service (GPRS) Tunnelling Protocol (GTP) tunneling (http://en.wikipedia.org/wiki/GPRS_Tunnelling_Protocol). E.g. a downstream IP user data packet (i.e. a packet towards the UE) between the PGW 104 and the SGW 105 is encapsulated in a GTP header and an outer IP transport header. The GTP header contains a Tunnel Endpoint ID (TEID) indicating which user, i.e. which UE 101, this packet belongs to. The outer IP transport header has the SGW 105 has destination address. There is a similar setup between the SGW 105 and the BS 102, but there a downlink packet has the BS address set as destination address in the transport IP header.
FIG. 1 illustrates further entities, such as Mobility Management Entity (MME) 106, Home Subscription System (HSS) 107, Serving GPRS Support Node (SGSN) 108, Policy and Charging Rules Function (PCRF) 109 for completeness. Moreover, two other exemplifying radio access networks, i.e. UTRAN 110 and GSM EDGE Radio Access Network (GERAN) 111, where GSM denotes Global System for mobile communication and EDGE denotes Enhanced Data Rates for GSM Evolution, are shown.
On transport level there may be additional layers, not shown in FIG. 1. E.g. the BS 102 and the SGW 105 may be in different sites, and the transport of packets between the sites may be performed through an encrypted transport tunnel. In such a setup, there may be a security gateway on both ends of the transport tunnel performing the encryption and decryption.
In order to fulfill upcoming requirements on the EPC architecture 100, it is believed that a completely redesigned architecture is required.
One such redesigned architecture is proposed to be based on Software Defined Networking (SDN). With software defined networking, a so called control plane is separated from a so called user plane, or data plane. A vision is that such architecture leads to a cheaper and more flexible network deployment. Networking services, such as network address translation, deep packet inspection, access control and the like, are no longer provided as monolithic boxes, but split up into the user plane performing the forwarding of user plane packets, and the control plane instructing the user plane how to perform the forwarding. A route, or path, that packets of a specific user, or even a specific flow of a user, takes through a collection of user plane forwarding elements is also known as a service chain.
Service chaining is today mainly used in a context where the end device does not move from a service chaining perspective. Typically, this is a fixed network environment or a mobile network where service chaining is used only above an anchor point.
In a service chaining environment where the end device does move, as would be the case when SDN is used in the above mentioned redesigned core architecture for a mobile wireless communication system, some new requirements are placed on the forwarding of the packets of that device. In particular, packets may get forwarded by a different set of forwarding elements after the moving. This implies that some kind of reconfiguration is needed in order to forward the packets of that device to the new location of that device.
Consider the network example in FIG. 2, in which a device, i.e. a UE such as a UEa 201 in the Figure, moves from a source base station (BS1) 202 to a target base station (BS3) 204. There are four base stations 202-205 and a number of Forwarding Elements (FEs), i.e. FE1 206 though FE7 212. The Forwarding Elements FE1-FE7 206-212 may be organized in this way for topological reasons; i.e. a first Forwarding Element (FE1) 206 may be close to the source base station (BS1) 202 but far from the target base station (BS3) 204.
Let's assume that the UEa 201 communicates with a peer 213, such as a computer, another UE, a server or the like, behind a further Forwarding Element (FE7) 212. In a naive implementation, each Forwarding Element in the UE-peer chain (of Forwarding Elements: FE1 206-FE2 207-FE5 210-FE6 211-FE7 212) will have at least one entry for the UEa 201. Worst case, there may be a single entry for every flow of the UEa 201. Now assume that the UEa 201 moves from the BS1 202 to the BS3 204. This would require new entries for the UEa 201 in a third Forwarding Element (FE3) 208 and a fourth Forwarding Element (FE4) 209. It would also require an update to the UEa 201 entries in a fifth Forwarding Element (FE5) 210, such that packets towards the UEa 201 are now forwarded to the FE4 209 instead of to a second Forwarding Element (FE2) 207. And finally, the entries of the UEa 201 in a first Forwarding Element (FE1) 202 and the FE 2 207 would need to be removed. All this causes a lot of control plane signaling towards the Forwarding Elements and node(s) controlling the Forwarding Elements. This is not a scalable solution.
SoftCell (ftp://ftp.cs.princeton.edu/techreports 2013/950. proposes one solution to this scalability problem. FIG. 3 is used to explain how the aspect of mobility with service chaining is solved in the SoftCell approach.
SoftCell defines an Access Switch (AS), such as AS1 320, AS2 321, AS3 322 and AS4 324 in FIG. 3, that are close to base stations, such as a source base station (BS1) 310. The Access Switch is logically located between the base stations and first Forwarding Elements, such as FE1 340 and FE3 342. The AS could be co-located with the BS, and could in fact be the first Forwarding Elements, again such as FE 1 340 and FE3 2 combined with a User Plane Function (UPF). In this terminology, the Forwarding Element performs solely the packet forwarding and the UPF performs some kind of operation on the packet and may even alter the packet. Combined they may perform one of the network services mentioned above.
The AS performs packet classification on traffic of UEs. Each packet is mapped to a policy. The policy defines which chain that packet belong to; i.e. which FEs and UPFs that packet needs to traverse. Packets are then aggregated onto three dimensions: policy, location (a base station ID) and UE ID. These aggregation dimensions can then selectively be used thereby limiting the number of entries in the FEs. E.g., FE5 344 in the figure above can base its downlink forwarding decisions on the location dimension, and does not need to take the UE dimension into account. FE 345 can base its uplink forwarding decision on the policy dimension, and does not need to take into account the location and UE dimension.
SoftCell proposes to code the three dimensions of policy, base station ID and UE ID in the source IP address and port of uplink packets. It is the AS that does this encoding. So the AS translates the source IP address and port used by the UE into a new source IP address and port, similar to a Network Address Translation (NAT) function. Between AS and peer this new IP address and port pair is used. The downlink packet from the peer includes new IP address and port as destination address. As the IP address topologically belongs to the AS, the downlink packet will arrive at the same AS. The AS then translates back to the original IP address and port known by the UE.
Now assume that a device, such as a UEa 301, moves from the BS1 310 to the BS2 311 in FIG. 3. The UEa 301 would thus move from a first Access Switch (AS1) 320 to a second Access Switch (AS2) 321. SoftCell proposes to keep existing flows routed via the AS1 320, in order to avoid a perceived IP address change for ongoing flows. So, for a flow that started when the UEa 301 was still on the BS1 310, the flow gets routed via the BS2 311 and the AS1 320 after the move. Only new flows get routed via the BS2 311 and the AS 2 321.
The SoftCell approach has a couple of disadvantages:                The encoding of the three dimensions into an IP address and port pair only works for flows that originate from the UEa 301. Because the peer is not aware of any encoding scheme, the SoftCell approach does not work for flows that originate from the peer.        After the UEa 301 has moved to a new BS, such as the BS2 311, existing flows are still routed via the AS1 320 associated with the old BS, i.e. the BS1 310. This introduces sub-optimal routing of such flows. This is in particular a disadvantage for long-lasting flows.        Assume that the UEa 301 has a number of active flows towards a peer. It then moves to a new BS, such as the BS2 311, and starts an additional flow. Then the peer 350 will perceive a new source address for the additional flow, even though that flow originates from the same UEa 301. This may confuse the peer 350 in certain scenarios.        SoftCell is basically introducing a Network Address Translation (NAT). This is acceptable for IPv4, as there already are so many NATs employed for IPv4 anyway, but is less appealing for IPv6.        Another solution is needed that removes these limitations from SoftCell, while at the same time keeping the advantages of SoftCell; i.e. scalable signaling towards the Forwarding Elements by aggregating flows.        